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standards and technologies 

within the computer and | The computer interoperability world changes rapidly. How can 

communications industry. you keep up with it? How can you decide what is even worth 
worrying about? 


In order to rapidly deliver accurate information on new 
developments, Advanced Computing Environments is publishing 
this monthly newsletter. The purpose of ConneXions--The 
Interoperability Report is to connect all the parties with strong 
interests in achieving interoperability--users, vendors, and 
researchers. Information in this field changes often. We will track 
this new information, analyze it and report it to you so that you 
know what is real for today and what lies ahead for the future. 


In this issue: ConneXions will: 
Letter fom Vint Geif 2 e Report what users are doing to solve networking problems 
and what they see as new requirements. 
The RFC Story....c.cccceeeee 3 e Analyze what vendors are offering as products and what 
their concerns are for the future. 
Internet Activities Board..... 4 e Describe the problems that researchers are facing, their 
plans for solving them, and their progress to date. 
Testing for TCP/IP............. 5 e Track the standards setting and selecting bodies (ISO, 
f CCITT, ANSI, IEEE, NBS, COS, MAP/TOP) as they 
Netbios and TCP/IP............ 6 progress in their efforts. 
Multi Vendor Support......... 7 | Planned articles will include interviews with leaders in all the 
communities of interest, articles on research in progress, protocol 
Gateways... 8 | extension activities, product category analysis, standards activities, 


and features on user successes and failures. ConneXions’ 
Editor-in-Chief, Ole Jacobsen, will interact with everyone who is 
influencing the field of interoperability. 


Advanced Computing Environments will continue to sponsor 
conferences and workshops for you. We hope you will find 
ConneXions to be an important additional resource for tracking the 
developments in the interoperability field. 


ConneXions is published by Advanced 

Computing Environments, 21370 Vai 

Avenue, Cupertino, CA 95014, 
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Welcoming Letter from Vint Cerf 


March 1, 1987 
Rem acu tetigisti! 


When Dan Lynch first told me about his plans for a newsletter about 
things TCP/IP, I was very glad that he was willing to try to satisfy 
the growing need for technical and topical information about the 
Internet protocols and the directions in which the user, vendor and 
research communities are heading in their applications. 


Having spent parts of my career in academia, government and industry, 
I am finding that the propagation of the Internet protocol suite has 
relevance to all three communities. The government will benefit from 
commercially available products; industry will benefit from the sales 
of related products and services; and the academic community will 
benefit from membership in the increasing inter- and intra-mural 
linkage of university computing and communication resources. 


Of course, none of the benefits will accrue unless the research, vendor 
and user communities are aware of the state of this technology, its 
potential problems and their solutions, future developments and 
research initiatives, and so on. Since not all members of the 
interested communities are connected together in an on-line fashion 
(yet!), this newsletter serves as a useful adjunct to the informal 
channels of information that now exist. 


Interoperability among computer systems is essential if we are to 
benefit from the adoption of common communication protocols. But this 
benefit does not come for free! It must be earned and paid for by hard 
work, much interaction among the user, vendor and research communities, 
extensive testing and widely available and understandable 
documentation. 


I am confident that Dan and his associates will succeed in their 
initiative to provide timely and high quality information to an 
enthusiastic and growing audience. 


P.S. For those of you who wondered, the Latin salutation, loosely 
translated, is "Right on!" [Literally: "You've touched the thing with a 
needle." One hopes this does not refer to a balloon or other delicate, 
gas-filled object!] 


Vint Cerf was Chief Scientist for the Information Processing Techniques Office and program 
manager for Internet research for DARPA from 1976 to 1982. At MCI he was vice-president of 
engineering where he developed the MCI Mail system from 1982 to 1986. Vint is currently 
vice-president of the Corporation for National Research Initiatives. He originally developed 
TCP/IP while he was a professor at Stanford University. 
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The RFC Story 


If you want to read the gospel on a particular protocol, you're likely 
to be pointed to an RFC. Before a proposed protocol is accepted for 
use in the Internet, it is discussed, reviewed and often revised by 
members of the Internet Activities Board (see separate story) and 
other interested parties. This dialogue is captured in a set of 
technical notes called Requests For Comments (RFCs). Their 
keeper and publisher is Dr. Jon Postel of USC-ISI. 


A reading of all the RFCs paints a fascinating picture of the 
development of the Internet. RFC 001, dated April 7th, 1969, was 
written by Steve Crocker and is entitled "Host Software". The 
Arpanet was just beginning to become a reality. BBN had already 
specified the software of the IMPs (nowadays called PSNs), and it 
was now time for the HOST working group to define the network 
software that would run on the hosts. To quote from RFC 001: 


"During the summer of 1968, representatives from the 
initial four sites met several times to discuss HOST 
software and initial experiments on the network. There 
emerged from these meetings a working group of three, 
Steve Carr from Utah, Jeff Rulifson from SRI, and Steve 
Crocker of UCLA, who met during the fall and winter. The 
most recent meeting was in the last week of March in 
Utah. Also present was Bill Duvall of SRI who has recently 
started working with Jeff Rulifson. 


Somewhat independently, Gerard De Loche of UCLA has 
been working on the HOST-IMP interface. 


I present here some of the tentative agreements reached 
and some of the open questions encountered. Very little of 
what is here is firm and reactions are expected.” 


Many of the issued RFCs have become accepted standards without 
further ado, a phenomenon which has led some cynics to say that 
RFC stands for "Requirements For Compliance". The authors of 
RFCs have from time to time displayed some sense of humor. One 
that comes to mind is Mark Crispin's "Telnet-Randomly-Lose 
Option" (RFC 748) issued on April 1, 1978. But for the most part, 
RFCs contain technical specifications, usually written such that 
programmers can actually implement protocols from them. 


In some cases the RFC will become an "Official ARPA Internet 
Protocol" and will be added to a list of such. The official list is itself 
an RFC which is issued periodically. (Currently RFC 991). This 
RFC also contains important comments about the current set of 
protocols and should definitely be read in conjunction with other 
RFCs. 


continued next page 
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How to get RFCs 


RFC 1000 
"A Reprise" 


The RFC Story (continued) 


You can order hard copies of RFCs from the DDN Network 
Information Center, or FTP them from the SRI-NIC.ARPA host. 
The NIC also maintains a list of RFCs by topic and, of course, the 
all-important numerical RFC Index. Most RFC's cost $5.00 per 
copy, apart from a handful which are over 100 pages and cost $10.00. 
A new RFC Subscription Service is now also available from the NIC; 
for $200.00 you'll get 12 months worth of of RFCs. 


Soon RFC 1000 will be issued. It is intended to be a reference guide 
and will provide a historical account of the Requests for Comments 
issued between 1969 and 1987, (RFC 001-999). This reference guide 
will also identify and categorize particular RFCs that may be of 
interest. These documents will be cross-referenced to provide 
information on what items are current, obsolete, or superseded. 


Getting Information 


e DoD protocol documentation may be ordered from: 


DDN Network Information Center 
SRI International, Room EJ291 
333 Ravenswood Avenue 

Menlo Park, CA 94025 

(800) 235-3155 or (415) 859-3695 


e CCITT and ISO documents may be ordered from: 


OMNICOM, Inc. 

501 Church Street, N. E. 
Suite 304 

Vienna, VA 22180 

(703) 281-1135 


The Internet Activities Board 


In the ARPA Internet, both operational and R&D issues are 
monitored by The Internet Activities Board (IAB). The IAB is a 
governing committee that divides its work among a number of 
Task Forces which work on various aspects of Internet research. 
We will be bringing you reports from some of their deliberations in 
future issues of ConneXions. The Task Forces are: 


e End-to-End Systems 

e Privacy and Security 

e Scientific Applications 

e Autonomous Systems 

e Internet Engineering 

e Internet Architecture 

e Applications 

e International Research Internet 
e Tactical Internetting 

e Robustness and Survivability 
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Protocol Testing for TCP/IP 


In the early years of TCP/IP products things were simple. There 
were only a few different implementations in the field and their 
implementors all talked to each other regularly. Now that we 
have over 100 implementations it is not the case that all 
implementors communicate with each other to eliminate 
incompatibilities. A simple case may illustrate the point. 


Silly Window There is a bad strategy for filling the data pipeline in TCP that can 
Syndrome cause extremely low data rates to be experienced. It is called Silly 
Window Syndrome (SWS). The standard distributed version of 4.2 
Berkeley Unix has this implementation bug in it and some 
vendors have fixed it, while many have not. (4.3 bsd has it fixed.) 
The causes and cures for SWS are dealt with completely in RFC 

813 by David Clark from MIT. So we might ask: 


Is testing needed? 

Who will pay for it? 

How soon can it happen? 
Is that too late? 


Financial support of TCP/IP could come from one of three sources: 


Who will pay ° Government pays for the testing lab. 
for testing? ° Vendors pay. 
e Private enterprise sets up a facility and charges vendors for 
testing. 


Or we just forget about testing TCP/IP. 
Will users ever Since it appears that testing most benefits the users, is there 
demand it? enough political clout in the user community to demand that 
TCP/IP products be tested before being sold? 
In future issues of ConneXions we will explore the testing issue 
for TCP/IP. We will explore these matters in detail. We also solicit 


your views. We want to hear from users. 


They pay the final bills. 
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Interoperability 
requires detailed 
agreements 


Multiple operating 
system support 


Internetworking 
for Netbios sought 


What is going on with Netbios and TCP/IP? 


About a year ago a number of vendors independently decided to 
make it possible for IBM PC applications (Netbios software 
interface) to run in a TCP/IP networking environment. These 
vendors already offered TCP/IP networking products and wanted 
them to interoperate with the growing number of Netbios 
applications. Products were announced by a number of vendors. 


Then along came the Mitre Corporation (in the role of coordinating 
large system purchases for the DoD) to ask the simple question: 
Will these different implementations of Netbios on TCP/IP 
interoperate with each other? Sadly, the answer was "no". Each 
vendor had chosen a different means of using TCP/IP to 
communicate with the Netbios interface. All it takes is a one-bit 
difference in any interface to make communication impossible. 
Mitre and the interested vendors formed a working group to 
examine the requirements and write a common specification that 
all could use. 


The two major technical challenges facing this group were: 


e Any "reasonable" operating system must be able to 
implement the specification. 

e Netbios applications should be able to operate in the 
Internet environment as well as in local networks. 


Ironing out the details of the first point took a while. The group 
wanted to be sure each operating system type could efficiently 
implement the new common interface to Netbios. (The idea is that 
applications running on Unix, Xenix, MVS, VM, VMS, CTOS, etc. 
would be able to communicate with Netbios applications running in 
the MS-DOS and PC-DOS world.) 


The second major challenge 
they faced is a key one: 
communication between 
separate networks. The 
scope of Netbios operation 
was originally intended only 
for a single network. 
Problems such as the one 
described to the right had to 
be solved. 


Problem: Netbios Naming 
in an Internet. 


In the Netbios world communicating 
entities (say, two programs) all have 
names. Names are obtained by a 

simple announcement scheme. If you 
want the name "Fred" you just broadcast 
your claim to the name "Fred" to every- 
one else on the network and if no one 
objects, you are "Fred". (If someone 
objects, you have to pick another name.) 
In the Internet case this scheme 

These problems have been presents two problems: 
addressed by the vendors and 
a two-step approach has been 
chosen for resolving them. 
In future articles we will 
describe the solutions to these 


problems and thereby shed 


e What happens when two formerly 
separate networks get connected 
(by a bridge/router/gateway) 
and there is a "Fred" on each one? 


° True broadcasting in the Internet is 
forbidden. It would quickly drown 


more light on inter- : 

eae , the universe. 
operability in a PC 
environment. 
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Multi-Vendor Support 


Just in case you're thinking that TCP/IP is a protocol suite of 
limited use, take a look at this list! Some 150 vendors now offer 
products which support TCP/IP and more are under development. 
If you know of other companies that should be added to the list be 
sure to let us know. We will be publishing this list from time to time. 


Apollo Computer 
Apple Computer 
Applicon/Schlumberger 
Applitek 

Arete 

ARINC Research 
Associated Computer Experts 
AT&T 

Auscom 

Aydin Monitor Systems 
BBN Communications 
BBN Labs 

BDM 


Beame & Whiteside Software Ltd. 


Bellcore 

Bridge Communications 
Britton Lee 

Butler & Curless 
Canaan Computer 
Celerity Computing 
Centram Systems 
Charles River 
CISCO 

cisco Systems 
Claflin & Clayton 


Communication Machinery Corp. 


Computer Network Technology 
Concurrent Computing 
Control Data Corporation 
Convergent Technologies 
Convex Computer 

Computer Science Corporation 
Counterpoint 

Cray Research 

Cydrome 

Dana Group 

Data General 

Datapoint 

Dawn Systems 

Digital Equipment Corporation 
Elxsi 

Encore 

Epilogue Technology 


Excelan 
Fibronics-Spartacus 
Ford Aerospace 
Fortune 

Frontier Technologies 
FTP Software Inc. 

GE Calma 

General Electric 

Gold Hill Computers 
Gould 

GTE 

Harris 

Hemispheres Hi-Tech 
Hewlett-Packard 
Honeywell 

IBM 

Imagen 

Interactive Systems 
Integrated Solutions 
Intergraph 
Intermetrics 

Internet Systems Corp. 
KEE 

Kinetics 

Lachman Associates 
Lisp Machine Inc. 
Little Machine Inc. 
Locus 

Los Alamos National Labs 
Marble Associates Inc. 
MARI 

Masscomp 

Maxim 
MICOM-Interlan 
Microport 

Mips 

Mitre 

Motorola 

Mt Xinu 

NBI 

NCR 

NCR Comten 

Network General Corp. 
Network Research Corp. 
Network Solutions 
Network Strategies 
Network Systems Corporation 
Nixdorf 


Novell 

Opus 

Oracle 

Panda Programming 


©- Phoenix Technology 


Plexus 

Prime 

Process Software 
Proteon 

Protocom Devices 
Pyramid 

Relational Technology 
Research Equipment Inc. 
Ridge Computer 
SAIC 

Santa Cruz Operation 
SCI Inc. 

Scope 

Sequent 

Silicon Graphics 

SMS Data Products Group 
Software Kinetics Ltd. 
Software Systems Associates 
SPARTA 

Spider Systems Inc. 
SRI International 
Sterling Software 
Stride Micro 

Sun Microsystems 
Symbolics 

Sytek 

Tandem 

Tektronix 

Texas Instruments 
THG 

3Com 

Tracor 
Ungermann-Bass 
Uniq 

Unisoft 

Unisys 

Univation 

Valid Logic 

Vitalink 

Wang 

Wollongong Group 
Xerox 

Xios Systems 
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Also called 
IP Routers 


Achieve network 
separation and 
interconnection 


Gateway is a 
special host 


Gateways 


If you have more than one campus/corporate network, you have 
probably already considered the possibility of connecting the 
networks together by means of a gateway. 


ConneXions will be bringing you a series of articles about 
gateways, and we hope to unravel the mysteries of what is at first 
glance a simple concept. Today's article is merely a cursory 
introduction to a subject which we will discover is very complex 
indeed. 


The term "gateway" is unfortunately used to mean a variety of 
things. Gateways may be used to tie together different kinds of 
physical networks or provide functional mapping at the 
application level. A host connected to two networks (such as 
BITNET and Arpanet), and providing mail-relaying between each 
network, would also be called a gateway. The kinds of gateways to 
be discussed here operate at the Internet Protocol (IP) level (and 
are often called "IP Routers"). Their function is to bridge together 
two or more networks of similar architecture. 


There may be many reasons for expanding from a single set of 
nodes to an internet of networks connected by gateways. The 
original Arpanet placed a limitation on the number of nodes, but 
this in itself was not the major reason gateways were needed. 
There were a number of different technologies emerging such as 
packet radio nets, satellite nets, and local area networks. All were 
based on TCP/IP, but with very different underlying technologies. 
Sharing resources and information in such an environment was 
certainly important, but of equal importance was the ability to 
isolate one network from another by means of the gateway. 


A gateway is really just a special host which is connected to two 
(or more) networks as shown in Figure 1. Note that this gateway 
has two addresses, --one on network A and one on network B--, 
and performs address translation between the two. Hosts on each 
network maintain (static or dynamic) tables which allow them to 
route packets to other networks via the gateways. The gateways 
exchange reachability and routing information by means of an 
interior gateway protocol (IGP). [In the Internet case this is GGP, 
see RFC 823]. A set of gateways that speak the same IGP is called 
an Autonomous System, (AS) and is usually controlled by a single 
administration. 


Figure 1 


New EGP being 
considered 
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Autonomous Systems may be connected together by another set of 
gateways as shown in Figure 2. In this case an exterior gateway 
protocol (EGP) is used to exchange reachability and routing 
information. 


AS 1 AS 2 


From a vendor or a user point of view this situtation is complicated 
by the fact that there is more than one IGP in existence. The IGPs 
may be proprietary or undocumented, but we are fortunate to have 
one standard EGP (RFC 904) which - at least in principle - should 
allow networks from different vendors to interoperate. [As we 
explore the mysteries of gateways we will discover that this may, 
in fact, not always be possible. ] 


Important changes will be occurring in the EGP world. The 
Internet Engineering Task Force is looking at the future of EGP in 
light of the rapidly expanding Internet. The news from the recent 
meeting held at NASA Ames is that they are considering both a 
new standard (and documented!) IGP, and the interactions 
between such a protocol and a future version of EGP -"Son of 
EGP". A paper is being drafted which defines the functional 
requirements for a new network routing architecture in the 
Internet. We will bring you more information about this work as 
it emerges. 
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Research task 
forces reporting 


Tremendous 
growth of TCP/IP 


Future topics 


From The Editor 


You are holding the Premiere Issue of ConneXions - The 
Interoperability Report. In an attempt to satisfy the need for 
information exchange between users, vendors and the R&D 
community, we will be publishing this newsletter. 


You've probably already discovered that networking is hard, and 
that reading the written RFCs just isn't enough. There is a great 
deal of protocol "folklore" which is difficult to track, especially if 
you don't have access to the ARPA Internet (since a fair amount of 
this discussion goes on via electronic mailing lists). 


In addition, the research people hold regular Task Force meetings 
and ConneXions will be reporting on the issues of importance to 
the vendor/user community. We would also like to act as a 
conduit in the other direction: users and vendors should feel free 
to address their concerns and give input to the R&D community 
via this publication. 


With the emergence of ISO it is probably true to say that TCP/IP is 
a protocol with a finite lifetime, but I am encouraged to see a 
tremendous growth in the number of implementations and 
products based on TCP/IP coming out of the vendor community. 
Some of you knew me as the person who cataloged this 
information in the DDN Protocol Implementations and Vendors 
Guide, published by the SRI NIC (Network Information Center). 
Having held my finger on the pulse of TCP/IP, so to speak, I am 
sure that this protocol suite will be with us for many years to 
come. 


ISO is coming --no doubt about that-- and we think ConneXions 
should be following this development with an emphasis on 
migration from DoD to ISO protocols. There are already several 
migration strategies and government policy statements which will 
affect the timing of such a protocol change. 


We will be covering alot of ground with this publication. Here are 
some of the areas we will be exploring, but the list is by no means 
complete: 


Gateways and Autonomous Systems 

Netbios 

More efficient TCP/IP implementations 

Congestion (aka The ARPA Internet "Success-Disaster") 
The Naming Domain System 

Security and Authentication 

Testing and Certification 

War Stories or "How we do networking at XYZ" 


One thing is clear: We need your input. I know that there are a 
large number of wizards in the user, vendor, and R&D 
communities. I encourage you to step forward and help us make 
this publication a success. 


OL f jbm A 


Ole J. Jacobsen 
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Additional Sources of Information 


We hope you were able to join us at the TCP/IP Interoperability 
Conference, March 16-19 in Monterey, CA. That conference was 
heavily attended by users, vendors and researchers. We have 
plans for two more conferences in 1987 that may interest you. 


The first is an ISO Implementation Seminar to be held this 
September in Monterey, CA. This seminar will describe a 
complete implementation of the ISO stack of protocols by a team of 
people who have been working on it for 2 years. 


The second is a TCP/IP Interoperability Conference which is 
scheduled for early December in Washington, DC. It will focus on 
new developments in TCP/IP. 


If you are not a subscriber to ConneXions and wish to receive the 
detailed information on these upcoming events please contact 
Advanced Computing Environments so that we may place you on 
our mailing list. 


Advanced Computing Environments 
21370 Vai Avenue 
Cupertino, CA 95014 
408-996-2042 


UNIX is a trademark of AT&T Bell Laboratories. 

MS is a trademark of Microsoft Corporation. 

VMS is a trademark of Digital Equipment Corporation. 

IBM is a trademark of International Business Machines Corporation. 
Xenix is a trademark of Microsoft Corporation. 
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